Skunkware 98

home *** CD-ROM | disk | FTP | other *** search

/ Skunkware 98 / Skunkware 98.iso / src / net / bind-contrib.tar.gz / bind-contrib.tar / contrib / misc / dns-setup.doc < prev next >

Wrap

Internet Message Format | 1996-10-25 | 31.3 KB

Path: vixie!decwrl!spool.mu.edu!howland.reston.ans.net!xlink.net!fauern!rrze.uni-erlangen.de!not-for-mail From: fhn019@cd4680fs.rrze.uni-erlangen.de (Franziska Staedtler) Newsgroups: comp.protocols.tcp-ip.domains Subject: Setup a nameserver -- corrected version (long) Date: Tue, 19 Oct 1993 14:41:03 +0100 Organization: Regionales Rechenzentrum Erlangen, Germany Distribution: inet Message-ID: <2a0qpfEfj2@uni-erlangen.de> NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de Lines: 757 Summary: How to setup a nameserver Hello netters, this is the second (corrected) version of my little description to setup a nameserver. Thanks to Ruediger Volk for his comments which pointed out some errors to me. The alterations to the first version are marked with ! marks at the beginning of the lines. For a more detailed review on the subject I should recommend the really excellent book DNS and BIND by P. Albitz and C.Liu (O'Reilly & Associates, Inc) Thank you, Paul and Cricket, for that book. It helped me no end. Well, since I don't want to spread all the details of our local setup all over the world (i.e. hostnames and addresses) I wiped these details out by using a.b.c.d to refer to an ip address in dotted notation host.dep.secdom.topdom to refer to a full domainname of a host ("dep" is standing for one or more subdomain labels in the secondlevel domain "secdom" which in turn is part of the toplevel domain "topdom") Any comments and suggestions are welcome. Please use my email address fhn019@cd4680fs.rrze.uni-erlangen.de to contact me. Regards, Franziska ----------------------------------------------------------------------- Setting up a primary master nameserver for a non-internet host ============================================================== General comments: ================= We use EP/IX for the examples. EP/IX is the system used by the CD4000 systems of Control Data Systems, Inc. For all the files we have to setup for named to work, except /etc/init.d/netdaemons, the ";" indicates the beginning of a *comment*. All the datafiles of named contain entries that are called resource records (RR) The RRs follow the general syntax domainname ttl class type record-data where domainname gives the object the record is for; if domainname is blank named assumes that the record is for the object of the record before this record. ttl gives the maximum time the record data is considered valid; if ttl is blank than "minimum ttl" in the SOA-Record is used. class gives the class to which the record belongs. Valid classes are IN (internet) and ANY (any class) type gives the type of the record. There a many record types but we will use only SOA --> Start Of Authority NS --> Name Server A --> Address PTR --> PoinTeR MX --> Mail eXchanger HINFO --> Host INFO The records of these types are described when first used. data gives the data belonging to this record. If "data" contains parentheses (), the record can span multiple lines. There are two directives that can be used in datafiles: $ORIGIN domain. Indicates the origin for the domainnames in the following RRs. "domain." is appended to the domainnames given in the RRs. I.e $ORIGIN secdom.topdom. ==> "secdom.topdom." is appended to the domainnames of the following RRs in the datafile. If there is a RR like this host IN A address-of-host than named reads "host" as "host.secdom.topdom.". $INCLUDE filename Tells named to include the RRs in the specified file here. What we need: ============= * BIND running on our unix box (/etc/named) * bootfile for named (/etc/named.boot) * internal root nameserver data file (root.cache) * data file for the mapping of 127.0.0.1 to the name "localhost" (named.local) * data file for the hosts in the domain (named.hosts) * data file for the mapping if the ip addresses to the hostnames for the local domain (named.rev) * directory to put the data files in What we do: =========== 1. First we look for a file /etc/named which indicates the presence of BIND (= Berkeley Internet Domain Name Service). If /etc/named exists we check the system startup files (i.e. in /etc/init.d) whether named is started when the system goes multiuser. The script /etc/init.d/netdaemons is shipped with EP/IX and starts named if the bootfile is present. Example: In /etc/init.d/netdaemons we can find the lines if [ -x /etc/named -a -r /etc/named.boot ]; then /etc/named /etc/named.boot; echo " named\c" fi which start named if /etc/named.boot exists. 2. For named to start we have to generate a file /etc/named.boot. This is an ASCII file we can edit with our favorite editor. /etc/named.boot may look like the following: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Nameserver bootfile for secdom.topdom ; last change 93/01/27 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; @(#)named.boot.master 1.11 of 93/01/25 ; ; bootfile for master server fh-nuernberg ; directory /confdir ; ; type domain source host/file backup file ; primary secdom.topdom named.hosts primary b.a.IN-ADDR.ARPA named.rev primary 0.0.127.IN-ADDR.ARPA named.local primary . root.cache ! In the above file I deleted the line with the domain statement. Let's have a look on this file. The lines start at column one. The line directory /confdir tells named where to look for the data files. The line primary secdom.topdom named.hosts tells named that it is a *primary master* for the domain "secdom.topdom" and the data for this domain is in "named.hosts". The next line primary b.a.IN-ADDR.ARPA named.rev tells named that it is a *primary master* for the domain "b.a.IN-ADDR.ARPA" which is used to map the addresses to the names and the data for this domain is in "named.rev". The line primary 0.0.127.IN-ADDR.ARPA named.local tells named that it is a *primary master* for the domain "0.0.127.IN-ADDR.ARPA" which is used to map the address127.0.0.1 to the name localhost and the data for this is in "named.local". The last line primary . root.cache tells named that it is a *root nameserver* (= primary master for the root domain) and the data is in "root.cache". The general syntax of the "domain" lines is type domain source backup where type determines which *type* of service named should provide for the specified domain. *type* may be primary primary master server; holds the zone data on disk This server is authoritative for the specified domain. secondary secondary master server; gets the zone data off a primary server and stores it for a specified time (see also "SOA Resource Record" later) cache caching server; holds no zone data on disk,caches only addresses and hints (i.e. root servers) it learnt by queries. ("zone" data means data of the domain the nameserver serves; "zones" are parts of the overall address space of the Internet for which authoritative servers (= servers that hold the data for this part of the address space) exist.) domain gives the domain named serves; secdom.topdom --> subdomain of the toplevel domain "de" (see also "the internet address space") --> *map names to addresses* a.b.IN-ADDR.ARPA --> special domain to map *addresses to names* source gives the filename or the hostaddress that holds the zone data backup gives the name of a backup file (only used for secondary servers) The filenames (named.hosts, etc) used above are the names of the example files shipped with BIND. We can change these names if we like. The named bootfile (standard: /etc/named.boot) may be changed too but then we have to change the section in /etc/init.d/netdaemons where named is started too. 3. Since our host is a non-internet host (= has no connnection to the Internet) we have to setup a *root nameserver* for named to work correctly. In the above bootfile we told named to be a primary server for the root domain (indicated be a period (.) in the domain field) and look for the domain data in a file named root.cache in the data file directory /confdir. This file looks like the following ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; temporary root name server is host.dep.secdom.topdom. ; only to verify our mail configuration and until ; we are directly connected to the internet ; FS 08/12/93 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; . IN SOA host.dep.secdom.topdom. dnsadm.host.dep.secdom.topdom. ( 930813001 ; Serial 28800 ; Refresh 7200 ; Retry 6044800 ; Expire 172800 ) ; Minimum IN NS host.dep.secdom.topdom. ; ; make hase root name server ; secdom.topdom. 172800 IN NS host.dep.secdom.topdom. b.a.IN-ADDR.ARPA. 172800 IN NS host.dep.secdom.topdom. ; ; address records for hase ; host.dep.secdom.topdom. 172800 IN A a.b.c.d ; ; adding mx records for sendmail to function properly ; * IN MX 5 host.dep.secdom.topdom. *.topdom. IN MX 10 host.dep.secdom.topdom. This file has four types of RRs in it. Let's have a look on them. The first RR defines the Start-Of-Authority for the root domain (.). The SOA RR has the following general syntax: domain IN SOA sdom mbox (Serial Refresh Retry Expire Minimum) with domain is the name of the domain the SOA record is for IN SOA defines the record as a SOA record of class IN sdom full domainname of the host that holds the zone data mbox mailbox of the person responsible for the nameserver (The @ in the common syntax user@domain is replaced by a period here since @ has a special meaning to the RRs.) The "mbox" field is not use by the nameserver itself. It is reserved for humans to use. Serial Serial number of the datafile. This field should be updated whenever the datafile is changed. "Serial" is used to tell the secondary nameservers that zone data has changed and should be transfered off the primary inspite of the "Refresh" time not having expired. Refresh Tells the secondaries how often (in seconds) to check for the accuracy of their zone data if not notified of changes before. Retry Tells the secondaries what time to wait for getting the zone data off the primary after "Refresh" has expired and they couldn't contact the primary than. Expire Tells the secondaries time after which they should consider their zone data invalid when "Refresh" has expired and they were unable to contact the primary. After "Expire" has expired the secondaries will stop to answers queries concerning the zone. Minimum Time-to-live value for all RRs in the datafile that have a blank "ttl" field. This TTL is supplied with answers to queries to tell other nameservers how long the data can be considered valid (if they want to cache it) All time values are given in seconds. Now let's have a look at our SOA record for the root domain. The sole period in the "domain" field tells that this is the SOA for the root domain. "host.dep.secdom.topdom." in the "sdom" field says that this host holds the domain data. All the zone data we need for root is included in this file (root.cache) for our purpose. The next field indicates that mail concerning the nameserver should be send to dnsadm@host.dep.secdom.topdom. The "Serial" consists of the date (YYMMDD) of the last change and a three digit sequence number. The "Refresh" period is about 8 hours, the "Retry" is 2 hours and the secondaries should expire their data after about 16790 hours. The default TTL for all the RRs in this file is about 2 days. The next record is a *nameserver* record. This record (NS) defines a nameserver for a given domain. The record has the following syntax: domain ttl IN NS domainname-of-the-nameserver-host with domain name of the domain the nameserver is for ttl optional ttl field. If blank the "Minimum" in the SOA record is used. IN NS defines the record to be a "nameserver" record of class IN domainname-of-the-nameserver-host the full domainname (starting with the hostname and ending with a period) of the host that is running the nameserver. In our example there are three NS records. The first defines host.dep.secdom.topdom. to be the primary nameserver for the root domain. The second makes the same host a primary for the local domain (secdom.topdom) and third record makes it a primary for the corresponding IN-ADDR.ARPA.-domain. These two records are used for delegation of the two domains. Normally those records would have to be in the zone data of the "topdom"- and the "IN-ADDR.ARPA"- servers. Since there are no such servers in our net we delegate directly in root.cache. For named to find the nameserver host it has to have an "address" record which has the general syntax: domainname. ttl IN A ip-address-of-domainname with domainname. is the full domainname of the object the record is for. I use the term "object" instead of "host" here since "domainname." need not be a host. It is recommended to use full domainnames whenever possible since certain applications (i.e. sendmail) could otherwise run into problems. ttl optional ttl field. If blank the "Minimum" in the SOA record is used. IN A says that this is an address record for the class IN ip-address-of-domainname gives the ip address to be associated with the given domainname in dotted notation (a.b.c.d) In our example file host.dep.secdom.topdom. is associated with the ip address a.b.c.d. For sendmail we need MX records telling it where to deliver mail that is addressed to users in the root domain and in die topdom-domain (= our toplevel domain). The MX record has the general appearence: domain. ttl IN MX preference mailhost with domain. is the domainname of the object the MX record is for. ttl optional ttl field. If blank the "Minimum" in the SOA record is used. IN MX define the record as "mailexchanger" record of class IN. preference tells at which preference the record should be used. There can be more than one MX RR of "domain.". Then "preference" tells which record to prefere. "preference" is an integer between 0 and 65535. The record with the *lowest* preference value (numerical) is considered the *best*. mailhost full domainname of the host the mail for "domain." should be send to. In our example mail addressed to the root- and the topdom-domain is sent to host.dep.secdom.topdom. Since there is only one MX RR for each domain the preference value doesn't matter here. Now we have setup our internal root nameserver. We are now ready to setup the nameserver for our domain. Before doing this we shall have a look at "The internet name space" and "What a nameserver does". The internet name space ======================= Unlike the ip address space which is flat the "internet name space" has a hierarchical organization. It looks like a tree helt upside down. It starts with a root indicated by a period (.). Then there are several levels of domains in this tree. The level immediately following the root is named toplevel domains and used to group universities, companies, ... into larger organizations or countries. The toplevel domains are either named according to the business of the institutions that belong to them or according to the ISO country codes. So names are COM, EDU, NET, MIL, DE, UK, US, etc. The toplevel domains include so called second-level domains which represent institutions like universities and companies (i.e. "fh-nuernberg"). In the second-level domains there can be one or more levels of subdomains. It is not recommended to created too much levels of subdomains since the internet domain names are used for email addressing and it is somewhat trying to have all those subdomains in the email address. An internet domain name consists of several "labels" that are separated by periods (.). The "labels" are the names of the domains in the tree: host.subdX.,,,.subd2.subd1.second-level-domain.toplevel-domain where subdN is part of subd(N-1) for N between 1 and X. ! The labels are given (from left to right) in the order local --> ! remote with the *farest* (root) at the end (right) of the name. ! In the zone data files of the nameserver where we have a mechanism ! to state a default domain (given in /etc/named.boot or with the ! $ORIGIN directive in the zone data files) we can use a period (.) ! at the *end* of a domain name to mark it fully qualified. When we ! put the period at the end of a domain name in a zone file we tell ! the nameserver *not* to append the default domain to this name. ! The first label of a domain name may be a hostname (host) or ! a subdomain name (subdX). I don't want to tell here that a ! domain name *must* begin with a hostname but it *can* begin with ! a hostname. What a nameserver does ====================== An internet name server maps names to addresses The internet (ip) addresses are given in numbers of the form a.b.c.d which for a human are difficult to remember. So the internet namespace was created to provide *names* that can be used instead of numbers. These names have to be mapped to the numbers which the computers can use better. For a unix system there are two means to do this mapping: * /etc/hosts * DNS (domain name service), i.e. named For an institution with many hosts (each must have an ip address for communication with the other hosts) the /etc/hosts file will grow very large and due to frequent changes will get quite unmaintainable. So they have to use a *nameserver* to manage the mapping for their institution. Well, the mapping of names to addresses is only one half. What about mapping addresses to names? To do this a special domain was created IN-ADDR.ARPA. It would be quite unmanageable to maintain all those mappings around the world in only one nameserver. Therefore the namespace is split into parts that are called *zones*. For each zone there is an institution that is given the authority to maintain the data for this zone. This is called *delegation*. The institution which is authoritative for a zone runs the primary master nameserver for this zone. I.e. The zone data for fh-nuernberg (zone!) is maintain in the computer center of this institution. Setting up a primary nameserver for a local domain ================================================== In "Setting up a primary master nameserver for a non-internet host" we made a file /etc/named.boot which told named to be a primary for * the root domain (--> 3.) * the local domain (--> 4.) * the reverse-mapping-domains for the local domain and "localhost" (--> 5.) In 3. we made a datafile for the root domain. Now we have to build the datafile for our local domain. We will name this file named.hosts in /confdir. That file (as all the others mentioned here too) is owned be the root account. 4. named.hosts has the following RR types in it: SOA, A, MX, HINFO and CNAME. Only for the last two types I didn't give a description yet. domain. IN HINFO CPU OS with domain. is the domainname the record is for. IN HINFO This is a "host info" record of class IN. CPU gives the type of host, i.e. PC-486. OS gives the operating system the host is running, i.e. MS-DOS. domain. IN CNAME aliased-name. with domain. is the domainname the record is for. IN CNAME This is an "alias" record of class IN. aliased-name. gives the name that should be used instead of "domain." when searching for records associated with the object. Note: There *must not* be other records containing "domain." in their domain field if there is a CNAME record for it. We can use CNAME RRs for hosts that should have more than one hostname. Again it is recommended to use full domainnames. Caution!!!! We *must not* use CNAME records to define an alias for a whole domain or subdomain!!! CNAME records *may only* be used to define aliases for hosts (leaf objects in the namespace tree). Now what RRs does or datafile contain? First it *must* contain one (and only one) SOA record for our domain. This record looks similar to that described in 3. for the root domain. The domain field now contains a @ or the full name of our domain (secdom.topdom). Note: @ in the domain field tells named to use the "current origin" here. Be sure that it is setup correct otherwise better take the full domainname to avoid any complications. Following this record a NS record with blank domain field makes host.dep.secdom.topdom. the primary nameserver for our domain. For each host in our domain the datafile has to contain the following records: * an A record that gives the corresponding ip address * a HINFO record that gives the machine type and the operating system * a MX record that tells sendmail where to send mail for this host to. Since we want to use mail servers in our departments instaed of one big mail server in the computer center we must include MX records pointing to those mail servers. Further in order to allow mail addressed to user@department.secdom.topdom to be delivered we setup MX records for our subdomains (departments) pointing to the correct server. There are a few users in various departments that will get their mail delivered at the central server hosta in rz.secdom.topdom. Since we don't want to include their hosts (i.e. PCs) to the subdomain rz.secdom.topdom. we shall make them use user@secdom.topdom to be their mail address and put a MX record in our datafile that directs mail addressed to user@secdom.topdom to hosta.rz.secdom.topdom. Note: These users *must* have an account on hosta to get their mail delivered otherwise it is send back to the sender with a message "user unknown". 5. Mapping addresses to names: Now we have almost finished our setup. There is only one thing left: the mapping of addresses to names. This is done in named.rev in /confdir and in named.local in the same directory. For this mapping a special domain has been created: IN-ADDR.ARPA. We have to setup datafiles for the subdomains b.a and 0.0.127 of this domain. Note that we use the dotted notation (a.b.c.d) in reverse order here! If a host has the address a.b.c.d we will refer to it here using d.c.b.a.IN-ADDR.ARPA. The domain field of the RRs in named.rev (and named.local) is of the form d.c.b.a when the origin is IN-ADDR.ARPA for this file. named.rev contains the following types of records: * a SOA record for b.a.IN-ADDR.ARPA * a NS record that makes host.dep.secdom.topdom. the primary nameserver for this domain * a PTR record for each host given in named.hosts The PTR record looks like domain IN PTR full-domainname-of-the-host with domain Since we defined b.a.IN-ADDR.ARPA the origin for this file (in /etc/named.boot) we give here the *last* two bytes of the internet address in dotted notation in reverse order. I.e. if a host has the internet address a.b.10.2 associated with it in named.rev we give 2.10 in the domain field of the corresponding PTR record. IN PTR defines the record to be a "pointer" record of class IN. full-domainname-of-the-host here we give the full domainname of the host that has been given the internet address corresponding to "domain". Well, that's somewhat tricky. Let's have an example: In named.hosts we have a host with the following A record host.dep.secdom.topdom. IN A a.b.c.d Now let's create the PTR record for this host in named.rev. In the domain b.a.IN-ADDR.ARPA our host has the domainname d.c so the PTR record is d.c IN PTR host.dep.secdom.topdom. Now that we have created named.rev only named.local is to be created. named.local defines a special local domain 0.0.127.IN-ADDR.ARPA. that is associated with the special hostname "localhost". This hostname is given the ip address 127.0.0.1. Our named.local may look like the following ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; named.local for secdom.topdom ; last change 93/01/27 ; 93/05/27 -- sendmail changes ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; @(#)named.local 1.1 (fh-nuernberg) 93/01/25 ; $ORIGIN 0.0.127.IN-ADDR.ARPA. @ IN SOA host.dep.secdom.topdom. dnsadm.host.dep.secdom.topdom. ( 930817001 ; Serial 28800 ; Refresh 7200 ; Retry 6044800 ; Expire 172800 ) ; Minimum IN NS host.dep.secdom.topdom. 1 IN PTR localhost. Note: The network 127.0.0 is not a valid network to contain hosts. It is only used for testing. Packets addressed to 127.0.0.1 should *never* leave the local host. Setting up a primary nameserver for an internet host ==================================================== ! When our host gets connected to the Internet (after serveral organizational ! work done) we have to change our configuration slightly. There are two ! places we have to make changes at: 1. We have to alter /etc/named.boot to let our host find the real internet root nameservers. We have no longer to fake a root nameserver. The line primary . root.cache should be replaced by cache . root.cache 2. We have to take the official root.cache file now. This file may have the following contents: ; ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . <file>" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher at RS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; file named.root ; ; last update: April 21, 1993 ; related version of root zone: 930421 ; . 99999999 IN NS NS.INTERNIC.NET. NS.INTERNIC.NET. 99999999 A 198.41.0.4 . 99999999 NS KAVA.NISC.SRI.COM. KAVA.NISC.SRI.COM. 99999999 A 192.33.33.24 . 99999999 NS C.NYSER.NET. C.NYSER.NET. 99999999 A 192.33.4.12 . 99999999 NS TERP.UMD.EDU. TERP.UMD.EDU. 99999999 A 128.8.10.90 . 99999999 NS NS.NASA.GOV. NS.NASA.GOV. 99999999 A 128.102.16.10 99999999 A 192.52.195.10 . 99999999 NS NS.NIC.DDN.MIL. NS.NIC.DDN.MIL. 99999999 A 192.112.36.4 . 99999999 NS AOS.ARL.ARMY.MIL. AOS.ARL.ARMY.MIL. 99999999 A 128.63.4.82 99999999 A 192.5.25.82 . 99999999 NS NIC.NORDU.NET. NIC.NORDU.NET. 99999999 A 192.36.148.17 ; End of File ! Here I replaced the copy of the root.cache file! ! There is some administrative work we have to do (if we haven't done ! it yet). We have to inform the administrators of our parent domain ! about the nameserver(s) we have installed. We have to tell them ! 1. the full domain names of our primary and at least one secondary ! nameserver for our zone ! 2. the internet addresses of these servers. ! ! We have to name at least to servers for our zone that are physically ! (i.e electricity) independent. The reason for this is that one of ! the nameservers for a zone should be available at least. ! So we have to get someone external to run a secondary server for ! our zone. Well that's all. Setting up a secondary nameserver ================================= ! Well, for a secondary nameserver we have to make three files. ! The type of nameserver (primary/secondary) is determined on a zone ! basis. The same machine can be a primary for one zone and a ! secondary for another zone. Which type of nameserver we run for ! which zone we have to give in the file /etc/named.boot. ! Here we assume a server which is secondary for our zone and ! primary only for the zone 0.0.127.IN-ADDR.ARPA which is for ! the host running the server only. 1. /etc/named.boot may look like the following: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Nameserver bootfile for secdom.topdom ; last change 93/05/27 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; @(#)named.boot.master 1.11 of 93/01/25 ; ; bootfile for secondary master server fh-nuernberg ; directory /usr/name.dir ; ; type domain source host/file backup file ; ;cache . root.cache secondary secdom.topdom a.b.c.d named.bak secondary b.a.IN-ADDR.ARPA a.b.c.d rev.bak primary 0.0.127.IN-ADDR.ARPA named.local ; ; ! In the above file I deleted the line with the domain statement. 2. named.local will be exactly analogous to the one described when "Setting up a primary master nameserver for a non-internet host (5.)" 3. root.cache is the same as described when "Setting up a primary nameserver for an internet host (3.)" Note: Here I assume we have a internet connection. If we don't have a connection to the internet and we have previously configured an internal root nameserver as described at the beginning of this document we may use the following root.cache file for our secondary that points to our "fake" root server: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; temporary root.cache file for a ;secondary without internet connection ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; . 99999999 IN NS host.dep.secdom.topdom host.dep.secdom.topdom. IN A a.b.c.d 4. Get named started with the appropriate startup file.